Some microprocessors support multiple, disjoint instruction sets which can be selected or changed during program execution. When using such a microprocessor, the program development tools, such as a compiler, assembler, linker, debugger, must manage the state of the processor. These program development tools must track and control which instruction set should be employed at each point in the program.
The version 7 of an ARM microprocessor is capable of executing in either of two disjoint instruction sets. The first instruction set is called the ARM instruction set. All ARM instructions are 32 bits in length. This was the original instruction set for the family of microprocessors. The 32 bit instructions permit coding many functions as well as enabling specification of two source registers and a destination register. The ARM instruction set is constructed according to the reduced instruction set computer (RISC) model. Instruction sets employing the RISC model are generally known for their speed of computation due to reduced decode complexity and simplified operation model. The second instruction set is called the THUMB instruction set. All THUMB instructions are 16 bits in length. The THUMB instruction set is a subset of the ARM instruction set. During the decode phase the microprocessor transforms each THUMB instruction into the corresponding ARM instruction. Operations coded in the THUMB instruction set generally operate more slowly than equivalent operations coded in the ARM instruction set. This is due to the additional decode processing and the limitations of the less rich set of instructions. However, functions coded in the THUMB instruction set generally require less program memory than equivalent functions coded in the ARM instruction set. The reduced length of the THUMB instructions relative to the ARM instructions produces this result. This is advantageous especially for portable embedded processors which may have limited memory space. The ARM microprocessor has two states: the ARM state, in which it executes only ARM instructions; and the THUMB state, in which it executes only THUMB instructions. Both instruction sets contain an instruction which changes the microprocessor to the other state.
The process of changing between the ARM and THUMB states is expensive in time. The ARM microprocessor is pipelined, that is, portions of plural instructions are executing in different hardware at the same time. Thus the microprocessor may fetch one instruction, decode an earlier instruction, execute a yet earlier instruction and store the results of a still earlier instruction. Upon changing from one state to another, all later instructions in the instruction pipeline are in the wrong instruction set. Thus the instruction pipeline must be flushed and reloaded. This process idles and wastes computational resources which could otherwise have been devoted to performing the flushed instructions. As a result, the accepted practice changes states only on function entry and exit. Therefore, any particular function is either entirely coded in ARM-state instructions or in THUMB-state instructions.
In a typical application, it is desirable to have some functions compiled in ARM state and other functions compiled in THUMB state. For example, some time critical operations and often used inner loops would be coded in the faster ARM instruction set. Other operations which are not time critical would be coded in the THUMB instruction set. This would result in a generally smaller program code size with little speed degradation. The decision of how to compile a particular function is typically decided by the programmer. In such a program, the compiler must generate code for a function in one state which may be called by code in the other state. The compiler must also generate code for a call to a function with an unknown state to support separate function compilation.
In the prior art the general solution is to generate veneer functions for each function. A veneer function manages the state change when the function is called by code in the other state. To illustrate, for an ARM-state function called "xyz", we would have the following veneer function:
______________________________________ xyz.sub.-- veneer: &lt;change to ARM state&gt; THUMB instruction(s) call xyz ARM instruction &lt;change to THUMB state&gt; ARM instruction(s) &lt;return to caller&gt; THUMB instruction ______________________________________
In this example, calls to "xyz" from THUMB-state code would generate a call to "xyz.sub.-- veneer." The "xyz.sub.-- veneer" function changes to the ARM-state, calls "xyz", restores the THUMB-state, and returns to the caller. ARM-state code may call "xyz" directly. The reverse occurs for a THUMB-state function "uvw":
______________________________________ uvw.sub.-- veneer: &lt;change to THUMB state&gt; ARM instruction(s) call uvw THUMB instruction &lt;change to ARM state&gt; THUMB instruction(s) &lt;return to caller&gt; ARM instruction ______________________________________
In this case, all calls to function "uvw" from ARM-state code would generate a call to "uvw.sub.-- veneer". THUMB-state code would call "uvw" directly.
This procedure presents a problem to the development tools. The development tools must determine when veneers are needed for a function. Producing unneeded veneers in the object code would needlessly increase the code size. The development tools must insert the veneers as required. Finally, the development tools must rewrite all calls which require a state change to call the corresponding veneers. Ideally this process should be seamless and transparent to the user programmer.
The prior approach to this problem uses the linker during the final link. The linker first reads all the object code functions. The linker then identifies the compiled code state of each function. The linker next determines for each function if it is ever called by a function which is compiled in the opposite state. For each such function, the linker must generate a corresponding veneer. For an ARM-state function, the linker generates a THUMB-state veneer. For a THUMB-state function, the linker generates an ARM-state veneer. The linker determines for each call instruction for code for either state if the destination of the call is compiled in the opposite state of the call instruction. If so, the linker must rewrite the call instruction to call the corresponding veneer.
There are several difficulties with this prior art approach. The linker must identify the object code associated with each function and the state in which it is compiled. The linker needs to be able to generate or modify instructions. Providing these capabilities is a major disadvantageous complication for a target-independent linker. These tasks are not particularly complex. However, these tasks are not normally within the scope of what a linker is expected to do. Accordingly, providing these additional capabilities to a linker presents major problems.